Montaje y pulido de niveles

Sesión 1

Profesor

  • Carlos León <cleon@ucm.es>
  • Profesor FdI
  • Docencia MVJ: Arquitectura UE, prácticas diseño de niveles, tutor de proyectos
  • Videojuegos, Creatividad Computacional y Sistemas Cognitivos
  • Grupo de investigación NIL
  • Despacho 444 FdI

Introducción y objetivos

Motivación

Uno de los roles más comunes en el diseño de videojuegos es el de creación de mapas/niveles, este módulo está pensado para reforzar vuestra habilidad como creadores de estos contenido

Objetivos

Saber crear de principio a fin niveles con una buena base técnica (objetivo, ideación, despliegue, comprobación…)

  1. Poner en práctica la teoría para crear niveles (en contraposición a mecánicas)
  2. Pulir nivel para jugabilidad y objetivos
  3. Hacer QA útil y aplicarlo

En concreto

Creación por parejas de 3 niveles para:

  • Un scroll lateral de saltos
  • Un top-down dual-stick
  • Un FPS

Las implementaciones disponibles ya os la damos hechas

No hace falta que cambiéis nada, pero no está prohibido

Están basadas en contenido core de UE para facilitar documentación y modificación

La pareja ideal

Tenéis libertad para crear parejas, pero los equipos en los que se combine capacidad de programación con capacidad de diseño, generalmente, funcionarán mejor

Pulido

Los niveles no solo tienen que ser jugables, también dar buena sensación y buen equilibrado

Para ello haremos un poco de «trampa», permitiendo cambiar los parámetros de las mecánicas

QA

Probaremos mucho nuestro juego, y una vez nos satisfaga, haremos evaluación cruzada

Los resultados de esta evaluación deberán servir para retocar

Aspectos opcionales

  • Programar BP en UE4 (aunque podremos)
  • Pulir aspectos visuales o sonoros (que son importantes)

Cómo hacer cada nivel

Proceso

  1. Redactar el concepto general del nivel, destacando los objetivos
  2. Estudio de alternativas similares en juegos (no hace falta hacerlo exhaustivo)
  3. Listado de elementos principales (geometría, dinámicas…) con los que se va a conseguir trabajar los objetivos, justificados y de dónde se saca la inspiración
  1. Geometría/mapa/esquema «en papel» del nivel, con objetos y enemigos, justificando cada parte
  2. Implementación en UE
  1. Pruebas y pulido, documentado. Entre otras preguntas (todas las que se puedan) hay que saber:
    1. ¿Cuánto tarda de media un jugador que juega por primera vez? ¿Uno que sepa?
    2. ¿Dónde suele morir o atascarse? ¿Por qué?
    3. ¿El jugador cumple objetivos de nivel?
    4. ¿Qué ocurre cuando modificamos los parámetros de nivel?
    5. ¿Está ocurriendo lo que queríamos que ocurriera (dinámicas, uso de elementos)?
  1. Aplicación de los resultados de las pruebas en el prototipo, explicando qué se ha hecho y por qué
    1. ¿Cuántos usuarios?
    2. ¿Qué hemos descubierto?
    3. ¿Cómo hemos pasado los hechos a datos?
    4. ¿Cómo se han pasado los datos a modificaciones?

Romper los juegos

Evidentemente, cuando hagamos las pruebas con los equipos de nuestros compañeros, nuestra labor será que todo falle y vaya mal

Es la única manera de mejorar el gameplay

Entrega

Un .zip con:

  • Un documento (PDF, preferiblemente) con los puntos 1, 2, 3, 4, 6 y 7. El documento puede ser conciso y sencillo, lo importante es que estén las ideas. No hace falta ni escribir mucho ni dedicarle esfuerzo de maquetación
  • El proyecto de UE con la implementación (punto 5)

La idea es que la entrega sea el material que se ha hecho en clase (con algunas mejoras donde tenga sentido), el objetivo es no quitaros más tiempo de lo necesario fuera de las sesiones de clase

Notas para todas las prácticas

  • Mando

    Aunque no es estrictamente necesario, se pueden traer mandos (gamepads) para probar los juegos, principalmente para el dual-stick

  • Edición de parámetros

    Todos los parámetros de personajes, nivel y demás que se puedan usar para equilibrar están puestos en la categoría «Game» en UE

Whiteboxing

Whiteboxing es el proceso de crear los volúmenes de un nivel, sin tener en cuenta los detalles (las mallas 3D)

(También lo veréis como greyboxing, block out, brushes o brush actors)

Es el borrador de un nivel, en el que crearemos y experimentaremos con es espacio, distancias, tamaños, etc

Es una técnica muy buena para saber qué se quiere antes de «vestir» el nivel entero:

  • Podremos iterar rápidamente (sin esperar al contenido artístico)
  • Nos permite «aislarnos» de la parte estética
  • Podemos probar las mecánicas y dinámicas

Introducción al whiteboxing en UE

Veamos algunos aspectos básicos para crear geometría en UE

(Más información en la documentación de UE)

Figura 1: En UE se incluye la geometría como cualquier otro objeto de escena

Manipulación directa

Figura 2: Los objetos de whiteboxing se pueden rotar, mover y escalar como cualquier Actor

Colisión

Figura 3: Los objetos tendrán, directamente, una malla de colisión que corresponderá a su geometría

En teoría se puede cambiar la colisión con solidity, pero no funciona bien

Edición de geometría

Figura 4: Podemos pasar al modo de edición de geometría a través del menú superior

Figura 5: En este modo (Brush Editing) los vértices de los objetos son editables y puedo cambiar la forma de las mallas

Operaciones booleanas

Figura 6: Las operaciones booleanas me permiten «sumar» o «restar»

Colores en whiteboxing

Es muy útil añadir colores (materiales) a los bloques para indicar su semántica:

  • Verde: seguro
  • Rojo: dañino
  • Amarillo: objetivo
  • Azul: objeto

Figura 7: Para colorear geometría brush, elegimos el objeto, luego todas sus caras (Shift-J) y arrastramos material

Scroll lateral

Introducción

En esta parte se va a trabajar en la creación de un nivel para un juego de mecánicas clásicas y sencillas de arcade desplazamiento lateral

Sigue un sistema básico 2D en un nivel de desplazamiento abierto (se puede ir a cualquier parte dentro de la zona delimitada)

Celeste

  • Exigencia muy alta de nivel
  • Pero muy poco castigo al fallar
  • Poca rejugabilidad (si tienes mucho nivel, el principio es muy fácil)
  • Añade mecánicas + elementos de nivel
    • Doble y triple «salto» buenos para corregir

Super Mario World

  • SMW tiene infinidad de enemigos y mecánicas que van evolucionando
  • Mucho contenido, mucho opcional (rejugabilidad de niveles)
  • Habilidad de movimiento
    • No hay doble salto, hay que hacerlo bien a la primera
  • En general hay tiempo de sobra

Super Ghouls ’n Ghosts

  • Salto sin movimiento: es importante, en un side-scroller, que nos podamos mover durante el salto. Es irreal, pero evita que tengamos que planificar un salto y da más velocidad al juego (y posibilidades)
    • Hay un doble salto que permite corregir
  • Añade disparo/mecánicas lucha
  • Mecánicas muy constantes

Elementos y mecánicas de la práctica

Desplazamiento

Desplazamiento lateral sencillo (izquierda/derecha), a una velocidad parametrizable

Agacharse

El personaje puede agacharse, reduciendo su altura a un multiplicador (parámetro)

Salto

Salto sencillo, de altura parametrizable

Es posible añadir movimiento lateral al salto (es decir, cambiar la dirección en el aire), parametrizable respecto a la velocidad básica en el suelo

Varios saltos

En el atributo Possible jumps se puede cambiar el número de saltos que se pueden dar en el aire (1, 2, 3…)

Coger y lanzar objetos

Para cambiar la potencia de lanzamiento, se puede cambiar la variable Throw strength

Daño

Tenemos \(N\) puntos de vida (configurable como Life, puede ser que \(N=1\)), y el contacto con los enemigos que no daña nos resta puntos

El daño en configurable en el atributo Damage

Para cambiar la vida inicial, tenemos la variable Life (en el componente Damageable)

Caídas

Si caemos por un agujero, perdemos todos los puntos de vida y la partida se reinicia (blueprint Deep)

Gemas

Las gemas son coleccionables para el jugador

Se pueden usar como objetivo (maximizar gemas cogidas), o como condición para eventos

Pulsadores

Al ser tocados, un elemento del escenario desaparece (¿una barrera?)

Es configurable en el atributo Barrier

Enemigos

  • Vigía

    El vigía va hacia derecha o izquierda hasta que se tope con un obstáculo (y entonces se da la vuelta) o hasta que caiga de una plataforma a otra inferior (y sigue moviéndose) o al vacío, y muere

Eliminar enemigos

Podemos eliminar enemigos de varias formas (cada golpe puede tener hacer distinto daño):

  • Haciendo que caigan en trampas (ver Enemigos)
  • Lanzándoles objetos que les dañen

Cuando un enemigo es eliminado, desaparece de la escena

Fin del nivel

Figura 8: El nivel se acaba cuando llegamos al «portal de salida»

Objetivos

  • Crear un nivel de scroll lateral de 2-3 minutos de duración (sin speed run)
  • Nivel «lineal» (no necesariamente la geometría, pero sí el desarrollo: no se pasa 2 veces por un sitio)
  • Todas las mecánicas deberán ser usadas en el nivel
  • Justificar y explicar las razones y el impacto en el jugador de cada decisión de diseño

Cosas que poner en práctica

  • Gestión de tiempo de nivel
  • Bloqueo de avance con geometría/bloqueo
  • Desafío y distancias salto/alcance, midiendo dificultad
  • Ritmo desafío/descanso
  • Muestra de desafío y solución (enseñar bloque y enemigo antes de resolver)

Concepto de nivel

Ayuda mucho dar un concepto único de nivel:

  • Objetivo de nivel: ¿para qué es este nivel?
  • Idea base: ¿qué idea queremos desarrollar sobre él?
  • Desafío base: ¿qué es difícil en el nivel?
  • Evolución: ¿cómo es el desenlace del nivel?

Opcional

  • Doble salto (parametrizable con el atributo Possible jumps)
    • Que el segundo salto sea más corto
  • Es posible modificar, añadir o quitar mecánicas, pero siempre de forma justificada y consultándolo antes. El juego deberá ser fundamentalmente el mismo
  • Hacer un nivel más largo, o más niveles
  • Comparativa detallada con otros niveles de juegos con mecánicas comparables
  • Que la velocidad del jugador dependa de si lleva o no un objeto
  • Añadir tiempo (variables Time y HasTime en el game mode)

Sesión 2: Terminar prototipo 1, pruebas y captura de resultados

Compartir pantalla para toda la clase

Revisión inicial

Cada grupo:

  • ¿Hemos definido objetivos/ideas de nivel?
  • ¿Nos satisface el concepto?
  • ¿Se cumplen?

Preparación de pruebas

  1. Preparar prototipo que pueda ser probado por otros equipos
  2. Preparar cosas concretas que experimentar:
    • Lista de preguntas, averiguaciones, observaciones
    • Saber para qué quiero hacer cada pregunta, cómo voy a aplicar lo que vea

Sesión 3: Aplicación de resultados, retoques, informe y presentación

Pruebas cruzadas

  • Hacer lista de grupos (poner un nombre al grupo/nivel)
  • De cada grupo:
    • Un miembro irá a probar juegos
    • Otro se quedará a recibir testers (luego se cambia)
  • Tengamos cuidado con distancia
  • Si alguien no se siente cómodo con moverse, no está obligado

Resultado de pruebas prototipo

  • Redactar lo que hemos averiguado
  • Redactar lo que vamos a hacer (un plan concreto), y cómo esperamos que funcione

Aplicación de resultados en el prototipo

  • Aplicar el resultado de las pruebas al prototipo
  • Volver a efectuar pruebas, esta vez conclusivas: ¿el juego «funciona»?

Evaluación final de niveles

Cada grupo hará un pequeño informe (rápido y conciso) de cada uno de los otros niveles:

  • Cosas reseñables
  • Limitaciones encontradas
  • Bugs de nivel

Qué incluir en el informe final

  • Resumen de diseño
  • Mecánicas cambiadas
  • Mapas en texto
  • Plan de pruebas
  • Ejecución de pruebas y resultados
  • Datos de pruebas
  • Resumen de experiencia con otros juegos

Y, en general, todo lo relevante y todo lo que hemos ideo apuntando

Exposición global a la clase

Votaciones

Sesión 4: Dual-stick cenital

Zelda

  • Mecánicas que avanzan y desbloquean mundo y gameplay
  • Lucha sencilla, principalmente cuerpo a cuerpo
  • Ritmo lento, enfrentamiento basado en «saber qué hacer»
  • Puzzle, laberinto, descubrimiento

Enter the Gungeon

  • Armas y balas por todas partes
  • Dificultad creciente
  • Sensación arcade (si juegas muy bien, los recursos no importan tanto)
  • Pulido muy detallado

Hades

  • Diferentes estilos de juego según armas
  • Influencia de varios géneros (Diablo, roguelikes)
  • Gestión de avance en mazmorra
  • Economía de recursos y mejoras para avanzar
  • Core loop moderno, con mejoras y narrativa

Gauntlet

  • Pantalla compartida
  • Espacio para multiplayer
  • «Infinitos» enemigos
  • No hay munición
  • La vida es el recurso principal

Objetivos

  1. Hacer un nivel por habitaciones
  2. Hacer una mazmorra sin habitaciones (todo seguido)

Juego

Descripción

Juego top-down, dual-stick en el que hay que atravesar una «mazmorra» de habitaciones

Movimiento

Movimiento WASD /palanca izquierda, se apunta con flechas de dirección o palanca derecha

Vida

Tenemos una serie de puntos de vida, como en el juego de scroll lateral

El daño funciona de la misma manera

Al recibir daño, hay un pequeño empuje configurable en PushDamage

Armas

Tenemos varias armas posibles

Arma básica

El arma normal tiene poca potencia y tiene munición infinita

Shotgun

(Todos los juegos necesitan una)

Cadencia de disparo baja, poca munición y ataque de dispersión

Machine Gun

Más munición, cadencia de disparo muy alta

Disparo y recarga

Hay munición global por cada arma, y munición en el cargador

Cuando se agota el cargador hay que recargar (activamente)

El tiempo de recarga (único para todas las armas) se encuentra en Recharging time

Cada arma hace un daño específico que puede configurarse en Weapon damage

En la clase del jugador hay varios Maps usados para configurar las armas:

  • MaxMagazine (las balas que caben en cada cargador)
  • Weapon fire rate (cadencia de disparo por arma)
  • Has (las armas que tiene)

Enemigos

Los enemigos se mueven a través de una malla de navegación (NavMesh)

Hacen un daño Damage done, en la clase Enemy (clase padre)

Zombie

Te persigue y hace daño cuerpo a cuerpo

Se mueve mediante un árbol de comportamiento (que os explicarán más adelante)

En ShootTask está Distance threshold para la distancia a la que ataca

También Attack period que es el tiempo entre ataques

Pinchos

Si los tocas, te hacen daño

Powerups

Se pueden coger un power-ups que cambia la velocidad (Speed thing) durante Super speed time segundos en Super speed quantity

Puertas cerradas

Solo se pueden abrir con una llave (ver más adelante)

Recursos

  • Vida
  • Llave
  • Balas

Portal

El nivel se acaba en el portal, igual que en juego 2D

Opcional

  • Power-ups de invulnerabilidad y de potencia de disparo (u otras cosas)
  • Dash
  • Más enemigos
  • Tipos de llaves
  • Más armas (cuerpo a cuerpo, por ejemplo)
  • Habitaciones/nivel procedimental

Proceso

  1. Objetivos de nivel/gameplay
  2. Perfilado de mecánicas
  3. Planteamiento de mapa/habitaciones/nivel
  4. Diseño de pruebas (experiencia/nivel/preguntas)
  5. Montaje de escenario
  6. Pruebas piloto
  7. Aplicación de pruebas a versión final
  8. Conclusiones

Sesión 5: Prototipos (habitaciones y continuo) y QA piloto

Prueba piloto

Hacer pruebas cruzadas y ver qué se puede cambiar y por qué

Después, aplicar esos cambios y mejorar los prototipo

Sesión 6: Finalización dual-stick

Plan de cierre

Antes de acabar el juego, haremos un plan concreto para que se pueda cerrar y terminar el nivel completo

Montar el juego

Cerramos el nivel y pulimos

Pruebas finales

Hacemos prueba y generamos informe (con diseño, piloto y evaluación final)

En el informe tiene que estar tanto lo que escribimos nosotros como las opiniones de nuestros compañeros

Votación

Sesión 7: Shooter en primera persona

DOOM

  • Ritmo, batalla
  • Hay narrativa, pero secundaria
  • No ha realismo, hay arcade
  • Muchas balas, muchas armas
  • Se juega a «matar bichos»
  • Poca evolución de mecánicas

Might and Magic

  • Puramente informativo en las primeras versiones
  • Evoluciona hacia «FPS», pero mantiene rol
  • Las dinámicas globales cambian por desaparecer los turnos

Halo

  • Dinámicas de combate complejas
  • Mecánicas adicionales (conducir, torretas)
  • Tipos de armas para enemigos
  • Diseño detallado de terreno y enemigos

Half-Life

  • Flexibilidad de armas, pero cada arma está pensada para un enemigo
  • No hay demasiada munición (pero sí de sobra)
  • Puzzles
  • Entorno y narrativa potentes
  • Juego con saltos y físicas

Skyrim

  • El control ya no es preciso en cuerpo a cuerpo
  • Aparece control preciso «lento» con arco
  • Relación mundo/personaje que elimina arcade y crea exploración
  • Fusión 1ª/3ª persona (mismas mecánicas porque no importa precisión)

Portal

  • Reinvención de puzzles en 1ª persona
  • Físicas y ritmo lento
  • Juego de cámara e información constante
  • Niveles puzzle muy complejos que funcionan en 1ª persona

Objetivo

Hacer un nivel FPS

El escenario será continuo, pero habrá 3 «zonas» o entornos diferentes

Nos faltarán modelos para diferenciar el entorno, pero lo sustituiremos con formas geométricas claras

Juego

Las mecánicas van a ser las mismas que en el top-down, pero esta vez en primera persona

De hecho, puede ser interesante reutilizar las mecánicas que posiblemente hayáis añadido y comparar

El jugador aquí podrá también saltar (pero aquí no tiene más de un salto)

Pasar elementos de un proyecto a otro en UE

Figura 9: Se pueden migrar uassets entre proyectos

Proceso

  1. Objetivos de nivel/gameplay
  2. Perfilado de mecánicas
  3. Planteamiento de mapa/habitaciones/nivel
  4. Diseño de pruebas (experiencia/nivel/preguntas)
  5. Montaje de escenario
  6. Pruebas piloto
  7. Aplicación de pruebas a versión final
  8. Conclusiones

Comparación

  • ¿Cómo cambian los valores entre primera persona y top-down?
  • ¿Cómo cambia la percepción del entorno?
  • ¿Gestión de enemigos y ataque?
  • ¿Me pierdo?
  • ¿Funciona la misma geometría?

Sesión 8: Narrativa

Las historias

El valor de las historias en la experiencia de un videojuego es (como en casi todo) muy grande

Por tanto, vamos a contar, en nuestro nivel, una historia

Personajes no jugador (NPCs)

En el proyecto hay ahora un blueprint NPC

Este componente tiene una componente de tipo TextRender que contiene un atributo Text que se mostrará cuando el jugador «hable» con el actor

Además, el texto se activa automáticamente cuando estamos a menos de Talking distance (distancia, en el personaje principal) y el texto dura Show time segundos en pantalla (en el NPC)

Enlazar geometría e historia

Vamos a usar un esquema clásico principio-nudo-desenlace (aunque si encontráis una razón buena para otro esquema, adelante)

La geometría tiene que encajar con la narrativa contada (3 zonas, 3 episodios)

QA en la narrativa

  • ¿Se entiende la historia?
  • ¿Emociona la historia? ¿Qué emoción?
  • ¿Mejora la experiencia? ¿Cómo?
  • Preguntad por la percepción de tiempo, ritmo y evolución con y sin historia

Pruebas piloto

Es el momento de hacer pruebas piloto y, tras los resultados (que tienen que estar apuntados) retocar el prototipo de forma justificada, con lo que hayamos averiguado

Sesión 9: Finalización FPS (y lo demás)

Finalizando

  • Retocar FPS con los cambios de las pruebas
  • Aprovechar para montar la entrega (documentación y paquetes con los niveles)

Pruebas finales y presentaciones

Votación

Entrega

La entrega se hará por correo electrónico <cleon@ucm.es>, con el material contado en la primera sesión

Fecha de entrega: 31 de marzo

Recordad: intentad enviar lo que se ha hecho en clase, no es necesario avanzar mucho más los niveles